Nowadays, there are scenarios where a user with a user's equipment (hereinafter UE) can negotiate with a telecommunication network, via a signalling layer, service requirements such as quality of service (hereinafter QoS) and, more specifically, a required service bandwidth for a number of services, which are in fact carried through a separate bearer or connectivity layer provided by an access network. For the sake of simplicity, and given that the bandwidth required for a service may be usually indicated along with other parameters as QoS requirements, the term ‘bandwidth QoS’ is generally used throughout the present specification as referring to the bandwidth required for a service.
Amongst these scenarios, those providing an Internet Protocol (hereinafter IP) connectivity to users are particularly significant at present. In this context, the scenarios described throughout the present specification may include a so-called IP Connectivity Access Network (hereinafter IP-CAN) where the users can exchange IP packets through. More specifically, a bearer or connectivity layer is a media transport, capable of carrying a plurality of IP flows, and takes place at the traffic plane. An IP flow is a unidirectional flow of IP packets with the same source IP address and port number, the same destination IP address and port number and, likely, the same transport protocol. An IP flow is thus used to transmit IP packets between an origin and a destination. Each IP flow may be associated with a service, and several IP flows may be associated with the same service.
For instance, a first scenario may be one where the user negotiates service requirements, including a required bandwidth QoS, with an IP Multimedia Subsystem (hereinafter IMS), as specified in 3GPP TS 23.228 V7.6.0, whereas the services are actually carried through an IP-CAN such as a General Packet Radio Service (hereinafter GPRS) connectivity layer. In this first scenario, a Proxy Call Session Control Function (hereinafter P-CSCF) is an entry point to the IMS and is located in the signalling layer at the control plane, being thus aware of negotiated service requirements. On the other hand, the bearer layer in this first scenario is built up through a connection path established between the UE, a Serving GPRS Support Node (hereinafter SGSN), and a Gateway GPRS Support Node (hereinafter GGSN).
A second scenario may be one where the user negotiates service requirements with an application server (hereinafter AS), such as a streaming server for video download services or as an application server offering TV over an IP network (hereinafter IPTV-AS), whereas the services are actually carried through an IP-CAN such as a Wireless Local Area Network (hereinafter WLAN) connectivity layer. In this second scenario, the streaming server or the IPTV-AS are the entities in charge of negotiating the service requirements with the UE, and are located in the signalling layer at the control plane; whereas the bearer layer is built up through a connection path between the UE, a WLAN Access Point (hereinafter WLAN AP), a WLAN Access Gateway (hereinafter WAG), and a Packet Data Gateway (hereinafter PDG). New scenarios might be apparent by having different combinations of signalling layer at the control plane with bearer layer at the traffic plane.
On the other hand, a common architecture called Policy and Charging Control (hereinafter PCC) is currently developed under 3GPP TS 23.203 V7.1.0. This PCC is supposedly addressing all different types of access networks and is intended to control how media transported through the bearer layer is treated in view of corresponding service requirements negotiated through the signalling layer. In other words, the basic PCC architecture is suitable for being applied in scenarios where services are negotiated through the signalling layer, between user equipments and servers in the control plane; whereas said services are actually carried through the connectivity or bearer layer, possibly between originating and destination user equipments.
In accordance with the above 3GPP TS 23.203, the PCC architecture includes a so-called Policing and Charging Rules Function (hereinafter PCRF) in charge of defining network control for detection of particular IP flows associated with a given service, making decisions based on information received from the signalling layer by generating control rules to enforce the negotiated service requirements into the bearer layer, as well as notifying the service layer about significant events occurred in the bearer layer for a given service. In particular, these control rules may include policy rules and charging rules. This PCRF is preferably located in an intermediate entity enabled to communicate with a first entity in the control plane and with a second entity in the traffic plane. The PCC architecture also includes a so-called Policing and Charging Enforcement Function (hereinafter PCEF) in charge of detecting those particular IP flows associated with a given service, and enforcement at the bearer layer of those service requirements negotiated through the signalling layer by installing the above control rules received from the PCRF. The PCEF may be included in the traffic plane and supports the connectivity or bearer layer between originating and destination user equipments, or between application servers and user equipments. Apart from the PCRF and PCEF, the PCC architecture also includes an application function (hereinafter AF) for offering applications that require control of the IP bearer resources. In particular, the AF may reside in, or be an integral part of, a server in the control plane aware of negotiated service requirements. The AF communicates with the PCRF to transfer dynamic session information, namely service information including the negotiated service requirements, required for PCRF decisions and for generation of the control rules.
Regarding the above exemplary scenarios, and prior to registering a user in an application at the control plane such as the IMS or an appropriate application server, namely at the signalling layer, the user has to establish a bearer through the IP-CAN, that is, at the bearer layer. The establishment of a first bearer for a user through the IP-CAN implies the establishment of an IP-CAN session, and subsequent bearers may further be established for the user in said IP-CAN session. In particular, where the IP-CAN is a GPRS access network and the user intends to register into an IMS network, the user has to firstly activate a primary Packet Data Protocol (hereinafter PDP) Context through the GPRS access network for bearing the IMS signalling. Once this primary PDP Context has been activated, there is an active IP-CAN session for the user wherein further secondary PDP contexts may be subsequently activated. An IMS network generally makes use of a Session Initiation Protocol (hereinafter SIP) so that, for the purpose of the present discussion, IMS signalling is conventionally understood as SIP signalling. Likewise, the establishment of a bearer through the IP-CAN is understood as the activation of a primary PDP Context in scenarios having a GPRS access network as IP-CAN. Then, once the user has established a bearer through the IP-CAN, the user can register in the application at the control plane and can negotiate with the exemplary IMS, or with the exemplary AS, or with a destination user the service requirements to be applied to the transmission of media through the bearer layer.
Once the QoS requirements for a service, including the bandwidth QoS, have been negotiated, the traditional PCC architecture may be used to ensure the control of network resources. To this end, an AF located in the control plane and aware of negotiated service requirements for a service submits an authorization request message towards the PCRF that, based on received IP-CAN session information and specific policies, generates control rules to be downloaded to a PCEF located in the traffic plane and supporting the connectivity or bearer layer. Such control rules permit, amongst others, the assignation of resources in a proper way.
Nowadays, and in order to better using and administering network resources in teems of bandwidth QoS, each network subscriber is assigned a so-called ‘subscribed bandwidth QoS’ intended to limit on subscription basis the total bandwidth consumed by those services already authorized for a subscriber. In addition, each individual service such as Push To-Talk “PTT”, Mobile Multimedia Telephony “MMTel” or ‘Streaming’ is assigned a so-called ‘pre-emption priority value’ intended to determine those services previously authorized with lower priority than a subsequent service as part of a conflict resolution mechanism to be applied where the total bandwidth consumed by the previous and the subsequent services would exceed the assigned ‘subscribed bandwidth QoS’ for the subscriber. In accordance with the conflict resolution mechanism as currently specified for PCC, the pre-emption of those services with lower ‘pre-emption priority value’ allows the execution of other subsequent services with higher ‘pre-emption priority value’.
For instance, where a low priority Streaming service served by an IPTV-AS does not allow the execution of a higher priority service, such as an MMTel call, to be accepted due to the lower priority streaming service consuming all or most of the available resources for that subscriber, this pre-emption priority mechanism for conflict resolution allows the higher priority MMTel call to be served in detriment of the lower priority streaming service.
However, at the current deployment of the pre-emption priority mechanism for conflict resolution, there is no clear suggestion of what actions should be carried out for allowing the higher priority MMTel call to be served, and what actions should be carried out in detriment of the lower priority streaming service. By disregarding or disabling the control rules installed at the PCEF and corresponding to the lower priority services, one may infer that such sort of event, as other events detected on the traffic plane, might be reported from the PCEF towards the AF via the PCRF. The AF would not have other choice than terminating the service. On the other hand, given that the PCC architecture today is only expected to authorize or de-authorize a service from the PCRF towards the AF, one might also infer that the PCRF should de-authorize previously authorized services with lower pre-emption priority towards the AF in charge of such previous services and order de-installation of corresponding control rules towards the PCEF prior to authorizing subsequent services with higher pre-emption priority towards the AF in charge of such subsequent service and order installation of corresponding control rules towards the PCEF.
On the other hand, user experience would be that, with the current deployment of the pre-emption priority mechanism for conflict resolution, some services previously running have been disconnected or are malfunctioning without any apparent reason to justify it.